Service Level Agreement Management Service

ABSTRACT

A service level agreement management service can include a computer that can obtain network data that relates to a service. The network data can represent a service level agreement associated with the service. The computer can create a failure data set and an inventory data set that can be bound to one another to obtain an intermediate data set. A data partition of the intermediate data set can be selected based on a failure root cause. A failure estimator that estimates a probability of failure over time for the service due to the failure root cause can be determined, and a best-fit probability distribution can be identified. A failure model that represents failures over time for the service due to the failure root cause can be output, and the computer can determine if the service level agreement should be updated.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of and claims priority to U.S. patentapplication Ser. No. 17/317,011, entitled “Service Level AgreementManagement Service,” filed May 11, 2021, now allowed, which isincorporated herein by reference in its entirety.

BACKGROUND

For some network providers (e.g., carriers), service level agreements(also referred to as “SLAs”) can be critical components of outsourcingand technology vendor contracts. In particular, carriers or otherproviders may engage vendors (or be engaged as a vendor) to providemanaged services. The service level agreements can specify variousaspects of these vendor relationships such as quality of servicecommitments, downtime limits, penalties for failing to meet servicelevel agreement commitments, etc.

The terms of service level agreements can be renegotiated fromtime-to-time based on various considerations. Determining appropriatecommitment levels, however, can be difficult for a number of reasons.Similarly, it may be difficult to determine what aspects of a service orarchitecture create exposure for such service level agreements.

SUMMARY

The present disclosure is directed to a service level agreementmanagement service. A customer premises equipment can operate on acustomer premises. The customer premises equipment can access one ormore services for various functions and/or can enable a connectionbetween the services and one or more devices located at or in proximityto a customer premises. The services can have one or more service levelagreements that can define various aspects of the quality of serviceand/or quality of experience for the services, users of the services, orthe like. A network monitor can be configured to monitor the services,the customer premises equipment, and/or the devices; or these and/orother devices on or in communication with the network can be configuredto self-report performance and/or failure information to one or moreentities as illustrated and described herein.

In various embodiments of the concepts and technologies disclosedherein, a service level agreement management service can operate and/orbe hosted by a server computer. The service level agreement managementservice can be configured to obtain network data from the customerpremises equipment, the service, the devices, and/or other devicesand/or entities. The network data can include failure data that candescribe one or more failures of these or other entities; time datadescribing times of failures and/or times of entity installation;service level agreement data that describes one or more service levelagreements associated with the services and/or other entities;resolution data that can describe how failures have been remediatedand/or resolved; other data; combinations thereof; or the like. Theservice level agreement management service can analyze the network dataand generate, based on the network data, a failure data set and aninventory data set.

The failure data set can describe failures of entities such as servicesand/or devices accessing, using, or enabling use or access to, theservices; and time information associated with the entities such astimes between failures. The inventory data set can describe the entitiesand the time since installation for the entities. The service levelagreement management service can be configured to horizontally bind thefailure data set to the inventory data set so that each record in theresulting bound data sets will include a time value; either a time sinceinstallation (in the event of no failure) or a time between failures.The service level agreement management service can generate a failureestimator for the data set.

In some embodiments, the failure estimator can be generated for a subsetof the bound data sets and can be obtained by performing anon-parametric estimation of the probability of failure over time forthe data sets or subset. The service level agreement management servicecan also perform a fit of probability distributions to identify abest-fit probability distribution for the failure estimator. Thisbest-fit probability distribution can be output as a failure modeland/or associated parameters, in some embodiments. In some embodiments,the service level agreement management service can generate graphicalrepresentations of the failure models, for example in response to arequest, to enable visual representation of the failure estimator. Itshould be understood that this example is illustrative, and thereforeshould not be construed as being limiting in any way.

The service level agreement management service also can provide thefailure models to a service level agreement management entity, and theservice level agreement management entity can determine if one or moreservice level agreements associated with the service or other entitybeing considered should be updated based on an anticipated failure. If afailure is determined to be imminent, the service level agreementmanagement entity can generate one or more service level agreementupdates and provide those updates to an entity for implementation (e.g.,to adjust a service level agreement). In some other embodiments, theservice level agreement management service can generate the servicelevel agreement updates and provide those service level agreementupdates to various entities for implementation and/or for reportingpurposes. Thus, some embodiments of the concepts and technologiesdisclosed herein can be used to minimize risk associated with failing tomeet quality of service commitments by proactively changing associatedservice level agreements. It should be understood that this example isillustrative, and therefore should not be construed as being limiting inany way.

According to one aspect of the concepts and technologies disclosedherein, a system is disclosed. The system can include a processor and amemory. The memory can store computer-executable instructions that, whenexecuted by the processor, cause the processor to perform operations.The operations can include obtaining network data that can relate to aservice. The network data can represent a service level agreementassociated with the service. The operations further can includecreating, based on the network data, a failure data set and an inventorydata set, binding the failure data set to the inventory data set toobtain an intermediate data set, selecting a data partition of theintermediate data set based on a failure root cause, determining, forthe data partition, a failure estimator that estimates a probability offailure over time for the service due to the failure root cause,determining, for the failure estimator, a best-fit probabilitydistribution, outputting a failure model that represents failures overtime for the service due to the failure root cause, and determining,based on the failure model, if the service level agreement should beupdated.

In some embodiments, the computer-executable instructions, when executedby the processor, cause the processor to perform operations that furthercan include receiving, from a user device, a request for a graphicalrepresentation of the failure model; and providing, to the user deviceand in response to the request, the graphical representation of thefailure model. In some embodiments, the computer-executableinstructions, when executed by the processor, cause the processor toperform operations that further can include triggering creation of aservice level agreement update and delivery of the service levelagreement to the service. In some embodiments, the network data can beobtained from a network monitor that can be configured to monitorperformance of the service and a customer premises equipment. In someembodiments, the failure data set can describe a failure of a componentof the service and time data that can describe a time between a firstfailure of the service and a second failure of the service.

In some embodiments, the inventory data set can describe a component ofthe service and time data that can describe a time since an installationof the component of the service. In some embodiments, binding thefailure data set to the inventory data set can include horizontallybinding the failure data set to the inventory data set to obtain theintermediate data set having two or more records. Each of the two ormore records can identify a component of the service and can specify atime value associated with the component of the service. The time valuecan include one of a time between failures for the component of theservice or a time since installation of the component of the service.

According to another aspect of the concepts and technologies disclosedherein, a method is disclosed. The method can include obtaining, at acomputer that can include a processor, network data that can relate to aservice. The network data can represent a service level agreementassociated with the service. The method further can include creating, bythe processor and based on the network data, a failure data set and aninventory data set; binding, by the processor, the failure data set tothe inventory data set to obtain an intermediate data set; selecting, bythe processor, a data partition of the intermediate data set based on afailure root cause; determining, by the processor and for the datapartition, a failure estimator that estimates a probability of failureover time for the service due to the failure root cause; determining, bythe processor and for the failure estimator, a best-fit probabilitydistribution; outputting, by the processor, a failure model thatrepresents failures over time for the service due to the failure rootcause; and determining, by the processor and based on the failure model,if the service level agreement should be updated.

In some embodiments, the method can further include receiving, from auser device, a request for a graphical representation of the failuremodel; and providing, to the user device and in response to the request,the graphical representation of the failure model. In some embodiments,the method can further include triggering creation of a service levelagreement update and delivery of the service level agreement to theservice. In some embodiments, the failure data set can describe afailure of a component of the service and time data that can describe atime between a first failure of the service and a second failure of theservice.

In some embodiments, the inventory data set can describe a component ofthe service and time data that can describe a time since an installationof the component of the service. In some embodiments, binding thefailure data set to the inventory data set can include horizontallybinding the failure data set to the inventory data set to obtain theintermediate data set having two or more records. Each of the two ormore records can identify a component of the service and can specify atime value associated with the component of the service. The time valuecan include one of a time between failures for the component of theservice or a time since installation of the component of the service.

According to yet another aspect of the concepts and technologiesdisclosed herein, a computer storage medium is disclosed. The computerstorage medium can store computer-executable instructions that, whenexecuted by a processor, cause the processor to perform operations. Theoperations can include obtaining network data that can relate to aservice. The network data can represent a service level agreementassociated with the service. The operations further can includecreating, based on the network data, a failure data set and an inventorydata set, binding the failure data set to the inventory data set toobtain an intermediate data set, selecting a data partition of theintermediate data set based on a failure root cause, determining, forthe data partition, a failure estimator that estimates a probability offailure over time for the service due to the failure root cause,determining, for the failure estimator, a best-fit probabilitydistribution, outputting a failure model that represents failures overtime for the service due to the failure root cause, and determining,based on the failure model, if the service level agreement should beupdated.

In some embodiments, the computer-executable instructions, when executedby the processor, cause the processor to perform operations that furthercan include receiving, from a user device, a request for a graphicalrepresentation of the failure model; and providing, to the user deviceand in response to the request, the graphical representation of thefailure model. In some embodiments, the computer-executableinstructions, when executed by the processor, cause the processor toperform operations that further can include triggering creation of aservice level agreement update and delivery of the service levelagreement to the service. In some embodiments, the network data can beobtained from a network monitor that can be configured to monitorperformance of the service and a customer premises equipment.

In some embodiments, the failure data set can describe a failure of acomponent of the service and time data that can describe a time betweena first failure of the service and a second failure of the service. Insome embodiments, the inventory data set can describe a component of theservice and time data that can describe a time since an installation ofthe component of the service. In some embodiments, binding the failuredata set to the inventory data set can include horizontally binding thefailure data set to the inventory data set to obtain the intermediatedata set having two or more records. Each of the two or more records canidentify a component of the service and can specify a time valueassociated with the component of the service. The time value can includeone of a time between failures for the component of the service or atime since installation of the component of the service.

Other systems, methods, and/or computer program products according toembodiments will be or become apparent to one with skill in the art uponreview of the following drawings and detailed description. It isintended that all such additional systems, methods, and/or computerprogram products be included within this description and be within thescope of this disclosure.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a system diagram illustrating an illustrative operatingenvironment for various embodiments of the concepts and technologiesdescribed herein.

FIG. 2 is a flow diagram showing aspects of a method for managingservice level agreements using a service level agreement managementservice, according to an illustrative embodiment of the concepts andtechnologies described herein.

FIGS. 3A-3C are user interface diagrams showing various screen displaysgenerated by a service level agreement management service, according tosome illustrative embodiments of the concepts and technologies describedherein.

FIG. 4 schematically illustrates a network, according to an illustrativeembodiment of the concepts and technologies described herein.

FIG. 5 is a block diagram illustrating an example computer systemconfigured to provide a service level agreement management service,according to some illustrative embodiments of the concepts andtechnologies described herein.

FIG. 6 is a diagram illustrating a computing environment capable ofimplementing aspects of the concepts and technologies disclosed herein,according to some illustrative embodiments of the concepts andtechnologies described herein.

DETAILED DESCRIPTION

The following detailed description is directed to a service levelagreement management service. A customer premises equipment can operateon a customer premises. The customer premises equipment can access oneor more services for providing various types of functionality and/or canenable a connection between the services and one or more devices locatedat or in proximity to a customer premises. The services can have one ormore service level agreements that can define various aspects of thequality of service and/or quality of experience for the services, usersof the services, or the like. A network monitor can be configured tomonitor the services, the customer premises equipment, and/or thedevices; or these and/or other devices on or in communication with thenetwork can be configured to self-report performance and/or failureinformation to one or more entities as illustrated and described herein.

In various embodiments of the concepts and technologies disclosedherein, a service level agreement management service can operate and/orbe hosted by a server computer. The service level agreement managementservice can be configured to obtain network data from the customerpremises equipment, the service, the devices, and/or other devicesand/or entities. The network data can include failure data that candescribe one or more failures of these or other entities; time datadescribing times of failures and/or times of entity installation;service level agreement data that describes one or more service levelagreements associated with the services and/or other entities;resolution data that can describe how failures have been remediatedand/or resolved; other data; combinations thereof; or the like. Theservice level agreement management service can analyze the network dataand generate, based on the network data, a failure data set and aninventory data set.

The failure data set can describe failures of entities such as servicesand/or devices accessing, using, or enabling use or access to, theservices; and time information associated with the entities such astimes between failures. The inventory data set can describe the entitiesand the time since installation for the entities. The service levelagreement management service can be configured to horizontally bind thefailure data set to the inventory data set so that each record in theresulting bound data sets will include a time value; either a time sinceinstallation (in the event of no failure) or a time between failures.The service level agreement management service can generate a failureestimator for the data set.

In some embodiments, the failure estimator can be generated for a subsetof the bound data sets and can be obtained by performing anon-parametric estimation of the probability of failure over time forthe data sets or subset. The service level agreement management servicecan also perform a fit of probability distributions to identify abest-fit probability distribution for the failure estimator. Thisbest-fit probability distribution can be output as a failure modeland/or associated parameters, in some embodiments. In some embodiments,the service level agreement management service can generate graphicalrepresentations of the failure models, for example in response to arequest, to enable visual representation of the failure estimator. Itshould be understood that this example is illustrative, and thereforeshould not be construed as being limiting in any way.

The service level agreement management service also can provide thefailure models to a service level agreement management entity, and theservice level agreement management entity can determine if one or moreservice level agreements associated with the service or other entitybeing considered should be updated based on an anticipated failure. If afailure is determined to be imminent, the service level agreementmanagement entity can generate one or more service level agreementupdates and provide those updates to an entity for implementation (e.g.,to adjust a service level agreement). In some other embodiments, theservice level agreement management service can generate the servicelevel agreement updates and provide those service level agreementupdates to various entities for implementation and/or for reportingpurposes. Thus, some embodiments of the concepts and technologiesdisclosed herein can be used to minimize risk associated with failing tomeet quality of service commitments by proactively changing associatedservice level agreements. It should be understood that this example isillustrative, and therefore should not be construed as being limiting inany way.

While the subject matter described herein is presented in the generalcontext of program modules that execute in conjunction with theexecution of an operating system and application programs on a computersystem, those skilled in the art will recognize that otherimplementations may be performed in combination with other types ofprogram modules. Generally, program modules include routines, programs,components, data structures, and other types of structures that performparticular tasks or implement particular abstract data types. Moreover,those skilled in the art will appreciate that the subject matterdescribed herein may be practiced with other computer systemconfigurations, including hand-held devices, multiprocessor systems,microprocessor-based or programmable consumer electronics,minicomputers, mainframe computers, and the like.

Referring now to FIG. 1, aspects of an operating environment 100 forvarious embodiments of the concepts and technologies disclosed hereinfor a service level agreement management service will be described,according to an illustrative embodiment. The operating environment 100shown in FIG. 1 includes a customer premises equipment 102 (alsosometimes referred to by the acronym “CPE”). The customer premisesequipment 102 can operate in communication with and/or as a part of acommunications network (“network”) 104, though this is not necessarilythe case in all embodiments.

According to various embodiments, the functionality of the customerpremises equipment 102 may be provided by one or more gateway devices,routers, server computers, desktop computers, mobile telephones, laptopcomputers, set-top boxes, other computing systems, and the like. Itshould be understood that the functionality of the customer premisesequipment 102 may be provided by a single device, by two or more similardevices, and/or by two or more dissimilar devices. For purposes ofdescribing the concepts and technologies disclosed herein, the customerpremises equipment 102 is described herein as a gateway device. Itshould be understood that this embodiment is illustrative, and shouldnot be construed as being limiting in any way.

According to various embodiments of the concepts and technologiesdisclosed herein, the customer premises equipment 102 can interact withone or more services or other resources (“services”) 106A-N (hereinaftercollectively and/or generically referred to as “services 106”). Theservices 106 can provide services to the customer premises equipment102, and the customer premises equipment 102 can provide functionalityand/or access to the services 106 to various devices 108A-N that can belocated at and/or in communication proximity to customer premises 110,which can be associated with a customer or other user. Thus, it can beappreciated that the services 106 accessed by the customer premisesequipment 102 can be used by the customer premises equipment 102 and/orprovided to other devices 108 in communication with the customerpremises equipment 102.

According to various embodiments of the concepts and technologiesdisclosed herein, the customer premises equipment 102 and/or the devices108 in communication with the customer premises equipment 102, can haveservice level agreements (also sometimes abbreviated as “SLAs”) for theservices 106 accessed by the customer premises equipment 102. As isgenerally understood, service level agreements can set and/or specifyvarious aspects of interactions with and/or use of the services 106 suchas, for example, quality of service (“QoS”) commitments for the services106 to provide to users and/or to the customer premises equipment 102;metrics and/or parameters by which the quality of service associatedwith the services 106 will be measured (e.g., availability of a system,the service 106, resources, or other entities; an expected or knowntime-to-resolve for a detected failure; a not-to-exceed number ofincidents for a particular service 106, device, entity, or the like);priorities and/or priority levels associated with the services 106;other terms associated with use of the service 106 (e.g., duration ofthe agreements, etc.); and/or other terms as is generally understood.

According to various embodiments of the concepts and technologiesdisclosed herein, the service level agreement management service 112 canbe configured to manage the service level agreements associated with theservices 106. In particular, the service level agreement managementservice 112 can be configured to collect information relating to theservices 106, the service level agreements used to provide functionalityassociated with the services 106 to the customer premises equipment 102,and performance of the services 106 and/or the customer premisesequipment 102 to determine if any changes should be made to the servicelevel agreements. The functionality of the service level agreementmanagement service 112 for managing service level agreements will beexplained in more detail below after introducing additional elements ofthe operating environment 100.

In some embodiments of the concepts and technologies disclosed herein,the service level agreement management service 112 can be hosted and/orexecuted by a device such as, for example, a server computer 114.According to various embodiments, the functionality of the servercomputer 114 may be provided by one or more server computers,application servers, web servers, cloud computing devices, desktopcomputers, other computing systems, and the like. It should beunderstood that the functionality of the server computer 114 may beprovided by a single device, by two or more similar devices, and/or bytwo or more dissimilar devices. For purposes of describing the conceptsand technologies disclosed herein, the server computer 114 is describedherein as an application computer. It should be understood that thisembodiment is illustrative, and should not be construed as beinglimiting in any way.

The server computer 114 can operate in communication with and/or as apart of the network 104. As will be explained in more detail below, thenetwork 104 can correspond to and/or can be associated with a carriernetwork, so the service level agreement management service 112 can beused, in some embodiments, to manage service level agreements associatedwith the services 106 and/or the customer premises equipment 102. Itshould be understood that this example is illustrative, and thereforeshould not be construed as being limiting in any way.

In some embodiments, the server computer 114 can execute an operatingsystem (not illustrated in FIG. 1) and one or more application programssuch as, for example, a service level agreement management service 112.The operating system can include a computer program that can control theoperation of the customer premises equipment 102. The service levelagreement management service 112 can include an executable program thatcan be configured to execute on top of the operating system to providevarious functions as illustrated and described herein for managingservice level agreements using a service level agreement managementservice 112.

In particular, the service level agreement management service 112 can beconfigured to obtain, from a network monitor 116, network data 118. Thenetwork data 118 can include various information and/or other types ofdata that can relate to performance of one or more of the services 106,devices hosting and/or providing the services 106, the customer premisesequipment 102, the network 104, devices operating on and/or incommunication with the network 104, and/or other devices or entities.According to various embodiments of the concepts and technologiesdisclosed herein, the network data 118 can include failure data, timedata, service level agreement data, resolution data, other data, and/orother information and/or data.

The failure data can include information that can indicate and/ordescribe one or more failures of the services 106; devices or resourcesthat host and/or execute the services 106; the network 104; devicesassociated with the network 104; the customer premises equipment 102;and/or other entities. The failures data can indicate a type of failureexperienced and/or detected, a severity of the failure (e.g., whetherthe failure affected one function of a service 106, affected allfunctions of the service 106, took the service 106 offline, etc.); animpact of the failure (e.g., how many users, customer premisesequipment, and/or devices 108 were affected; a geographic scope of thefailure; etc.); and/or other aspects of the failure that can be used tounderstand the failure and its impact.

With regard to severity of the failures, the concepts and technologiesdisclosed herein can rely on various definitions of severity. Forexample, in some embodiments of the concepts and technologies disclosedherein, the severity of failures can be defined by one or more levels.In some embodiments of the concepts and technologies disclosed herein,subsets of failures can be generated, for example, based on severity ofthe failures. In some contemplated embodiments, severity of failures canrange from a value of one to four. In some embodiments, a severity oflevel one can indicate a critical problem with an application, service(e.g., the service 106), or network (e.g., the network 104), in which anincident stops the customer or user from functioning because theapplication, service (e.g., the service 106), or network (e.g., thenetwork 104) may be unusable and/or because the customer or user isotherwise unable to work. In a level one severity incident, no bypass orrecovery may be possible. It should be understood that this example isillustrative, and therefore should not be construed as being limiting inany way.

In some embodiments, a severity of level two can indicate a majorproblem with an application, service (e.g., the service 106), or network(e.g., the network 104) in which an impact of the incident on thecustomer business can be limited, but may not be prevented altogether.For example, the customer or user may have an alternative way to executetheir business without the application, service (e.g., the service 106),or network (e.g., the network 104); or the customer or user may sufferfrom performance issues that do not render the application, service(e.g., the service 106), or network (e.g., the network 104) entirelyunusable. Thus, in the level two severity incident, a bypass, recovery,or repair for the application, service (e.g., the service 106), ornetwork (e.g., the network 104) may be possible. It should be understoodthat this example is illustrative, and therefore should not be construedas being limiting in any way.

In some embodiments, a severity of level three can indicate a minorproblem with an application, service (e.g., the service 106), or network(e.g., the network 104) in which an impact of the incident on thecustomer business may be minimal and it may not be necessary for thecustomer or user to have an alternative way to execute their businessprocess without the application, service (e.g., the service 106), ornetwork (e.g., the network 104). In a level three severity incident,however, the current state and/or situation may not conform to theexpectations of the customer or user. It should be understood that thisexample is illustrative, and therefore should not be construed as beinglimiting in any way.

In some embodiments, a severity of level four can indicate that there isno problem with an application, service (e.g., the service 106), ornetwork (e.g., the network 104). Thus, a level four severity incidentmay indicate a call or other request for service information and/or acall or other communication used to provide a suggestion. It should beunderstood that this example is illustrative, and therefore should notbe construed as being limiting in any way. In some embodiments of theconcepts and technologies disclosed herein, only failures that are of aseverity level of one or two may be considered. It should be understoodthat this example is illustrative, and therefore should not be construedas being limiting in any way.

The time data can include data and/or other information that can be usedto determine time information associated with one or more failures, oneor more services 106, and/or one or more devices or other entitiesassociated with one or more services 106. For example, in someembodiments the time data can indicate and/or can specify a time betweenfailures (“TBF”), which can be defined for one or more service(s) 106and/or for one or more device(s) executing and/or hosting the one ormore service(s) 106). The time between failures can correspond to anamount of time that lapses from a first failure of a service 106, adevice hosting a service 106, and/or other devices or entities until asecond failure of a service 106, a device hosting a service 106, and/orother devices or entities. It should be understood that this example isillustrative, and therefore should not be construed as being limiting inany way.

In some other embodiments, the time data can indicate and/or can specifya time since installation (“TSI”) for a particular service 106, for adevice hosting and/or executing a service 106, for the customer premisesequipment 102, for the one or more devices 108, and/or for otherentities. In particular, the time since installation may be used forservices 106 that have not yet failed, in some embodiments, for exampleto track the amount of time the service 106 has been available and/orhas been use. The time since installation information can be useful, forexample, to project or predict a failure of a service 106, a deviceand/or entity hosting a service 106, or the like. Because the timebetween failures and/or time since installation can be used foradditional and/or alternative reasons, it should be understood that theabove example uses are illustrative, and therefore should not beconstrued as being limiting in any way.

The service level agreement data can include data and/or otherinformation that can describe service level agreements for one or moreof the services 106 and/or one or more customers, users, and/or otherentities provided with functionality by the services 106 (e.g., thedevices 108). Thus, the service level agreement data can describe, amongother things, a quality of service defined for a particular service 106and/or user of the service 106; one or more standards, metrics, and/orparameters (e.g., availability of a system, the service 106, resources,or other entities; an expected or known time-to-resolve for a detectedfailure; a not-to-exceed number of incidents for a particular service106, device, entity, or the like) that may be used to measure quality ofservice and/or other aspects of performance (e.g., to determine if thequality of service set by the service level agreement is met by theservice 106); priorities and/or priority levels associated with theservices 106 and/or users of the services 106; other terms associatedwith use of the service 106 (e.g., duration of the agreements, etc.);and/or other terms as is generally understood. Thus, the service levelagreement data can be used to understand the contours of one or moreservice level agreements for one or more services 106 and/or one or morecomponents of the one or more services 106. Because other aspects ofservice level agreements may be defined by service level agreement data,it should be understood that the above examples are illustrative, andtherefore should not be construed as being limiting in any way.

The resolution data can describe, for a particular failure, device,service level agreement, or other entity, a resolution for the failure.The resolution data can include trouble ticket information, downtimeinformation, and/or other information that can be used to determine howa failure was remedied, how long the remediation took, whether theremediation was in stages, entities that remedied the failure,combinations thereof, or the like. Thus, the resolution data can be usedto understand how a failure is resolved, timeframes for suchresolutions, entities involved in such resolutions, combinationsthereof, or the like.

The other data can include various other information that can be used tounderstand the services 106, use of the services 106, users of theservices 106, etc. Thus, the other data can include location information(e.g., for resources that provide the services 106, for users of theservices 106, etc.), vendor information, carrier information, networkrequirements for services 106, etc. As such, the other data can includeany information that may be used by the service level agreementmanagement service 112 as illustrated and described herein that is notseparately defined herein. Because the other data can include additionalinformation not explicitly illustrated and described herein, it shouldbe understood that the illustrated embodiments of the other data areillustrative and should not be construed as being limiting in any way.

The service level agreement management service 112 can be configured toobtain the network data 118. In some embodiments, the service levelagreement management service 112 can obtain the network data 118 fromthe network monitor 116, as explained above. In some other embodiments,the network data 118 can be provided to the server computer 114 (and theservice level agreement management service 112) by the customer premisesequipment 102, by the network 104 and/or other devices or entities onthe network 104, by the services 106, by one or more of the devices 108,and/or by other entities. The example embodiment, wherein the networkdata 118 is provided by the network monitor 116, is illustrative andshould not be construed as being limiting in any way.

The service level agreement management service 112 can be configured toobtain the network data 118 and to determine, based on an analysis ofthe network data 118, information relating to the services 106 such as,for example, one or more failures associated with the services 106 (ifany); times at which the failures occurred (if any); times sinceinstallation for the services 106 and/or components thereof; servicelevel agreements associated with the services 106 and/or users of theservices 106; locations of services 106 and/or users of the services106; combinations thereof; or the like. According to various embodimentsof the concepts and technologies disclosed herein, the service levelagreement management service 112 can be configured to create a devicefailure data set (“failure data set”) 120 based on the network data 118.

According to various embodiments of the concepts and technologiesdisclosed herein, the failure data set 120 can describe failuresassociated with the services 106 and a time between failures metricdefined for each service 106 that has failed. Thus, for example, thefailure data set 120 can define a first service 106A, a first timebetween failures defined for the first service 106A, a second service106B, a second time between failures defined for the second service106B, etc. It can be appreciated that in order to create the timebetween failures metric, the service level agreement management service112 may identify at least two failures of a particular service 106(e.g., based on the failure data in the network data 118) and determinea time between the two failures (e.g., based on the time data in thenetwork data 118). It should be understood that this example isillustrative, and therefore should not be construed as being limiting inany way.

The service level agreement management service 112 can be configured todetermine, for one or more or even all services 106, a time betweenfailures metric. Thus, it can be appreciated that the failure data set120 can represent one service 106, more than one service 106, and/or allservices 106 and a respective time between failures metric for any ofthe services 106 that have experienced at least two failures. It shouldbe understood that this example is illustrative, and therefore shouldnot be construed as being limiting in any way.

The service level agreement management service 112 also can beconfigured to generate, based on the network data 118, an inventory dataset 122 that can define a service inventory; times at which each of theservices 106 (and/or devices that provide the services 106) wereinitiated or brought online; combinations thereof; or the like. Thus, itcan be appreciated that each entry in the inventory data set 122 caninclude a time since installation metric, which can define a time thathas lapsed since the service 106 or device providing the service 106 wasactivated or otherwise initiated. Thus, for services 106 that have notfailed, the time since installation metric can be determined and stored(e.g., based on the time data of the network data 118). It should beunderstood that this example is illustrative, and therefore should notbe construed as being limiting in any way.

The service level agreement management service 112 can be configured tobind the failure data set 120 to the inventory data set 122. Inparticular, the failure data set 120 and the inventory data set 122 caninclude records that can be bound to each other horizontally, whichmeans herein that a row of data in the resulting data set (e.g., thedata set that results from binding the failure data set 120 to theinventory data set 122) can have failure data and either a time betweenfailures or a time since installation. Thus, it can be appreciated atthe data set that results from the binding of the failure data set 120to the inventory data set 122 can include failure data and time dataassociated with the failure data. This resulting data set is notseparately illustrated in FIG. 1, as this data set is an intermediatedata set in the creation of a model that can describe failures and theirassociated time data, as will be explained momentarily.

The service level agreement management service 112 can be configured togenerate, based on the intermediate data set (which as noted above iscreated by the horizontal binding of the failure data set 120 to theinventory data set 122), one or more failure models 124. The failuremodels 124 can be generated by the service level agreement managementservice 112 by applying various statistical operations on theintermediate data set.

In some embodiments of the concepts and technologies disclosed herein,the intermediate data set that can be obtained according to embodimentsof the concepts and technologies disclosed herein can include a datatable or other data structure. An example data structure is set forthbelow in TABLE 1. The example data shown in TABLE 1 shows a ticketcolumn indicating ticket identifiers for tickets received for failures,asset identifiers, a time to resolution (labeled “TTR”) for thefailures; a root cause indicator column, a severity (labeled “SVR”)column that can list a severity of the failures (as explained in moredetail below); a time since installation (labeled “TSI”) column; a timebetween failures (labeled “TBF”) column, and a censor column. In thecensor column, a value of 1 can indicate a failure of the correspondingasset (in that record), and a value of 0 can indicate that no failurehas yet occurred for the associated asset. Thus, in some embodiments,the censor column can be used to identify devices that have or have notexperienced a failure. Because additional and/or alternative data can beincluded in the intermediate data set and/or other data sets asillustrated and described herein, it should be understood that thisexample is merely illustrative and should not be construed as beinglimiting in any way. Additionally, it can be appreciated that the samplesize and/or time duration for the data in the intermediate data setand/or other data and/or data sets illustrated and described herein canbe set to ensure an accurate determination of the statistical model asillustrated and described herein. In one contemplated embodiment of theconcepts and technologies disclosed herein, the sample size can be setto five hundred qualified failures (of a severity level of one or two asillustrated and described herein in more detail below) and six thousandfive hundred devices in inventory without a failure over twenty-fivemonths of observation. It should be understood that this example isillustrative, and therefore should not be construed as being limiting inany way.

TABLE 1 Ticket Asset TTR Root Cause . . . SVR . . . TSI TBF Censor T_ID1A_ID1 50790 Application Error 1 TSI_1 13008 1 T_ID2 A_ID2 1117 CircuitOutage 1 TSI_2 72 1 T_ID3 A_ID3 553 Circuit Outage 1 TSI_3 12096 1 T_ID4A_ID4 9945 Hardware Failure 1 TSI_4 7752 1 T_ID5 A_ID5 50668Configuration 1 TSI_5 2424 1 T_ID6 A_ID6 2 Software Failure 1 TSI_6 47761 A_ID7 TSI_7 0 A_ID8 TSI_8 0 A_ID9 TSI_9 0 A_ID10 TSI_10 0 A_ID11TSI_11 0 A_ID12 TSI_12 0 A_ID13 TSI_13 0

In particular, in some embodiments of the concepts and technologiesdisclosed herein, the service level agreement management service 112 canbe configured to generate the failure models 124 by generating anestimated time to failure or between failures for a service 106, device,or other entity, and fitting one or more probability distributions tothe estimate to identify a best-fit distribution. In particular, in someembodiments, the service level agreement management service 112 can beconfigured to perform, on the intermedia data set (based on the failuredata set 120 and the inventory data set 122), a non-parametricestimation of the probability of a failure over time for a particularservice 106, device hosting a service 106, customer premises equipment102, devices 108, and/or other devices as illustrated and describedherein.

According to one example embodiment, the service level agreementmanagement service 112 can apply, to the intermediate data set (which asnoted above is created by the horizontal binding of the failure data set120 to the inventory data set 122), a Kaplan-Meier estimator (alsosometimes referred to a “Kaplan-Meier estimate”) or other type ofsurvival analysis, to generate an estimator of the probability offailure over time. In some embodiments, the Kaplan-Meier estimator (alsoreferred to as a product limit estimator) can be used to generate a“lifetime” estimator (hereinafter a “failure estimator” or “devicesurvival function”), which in the context of the concepts andtechnologies disclosed herein, can be a “lifetime” of a service 106,device, or other entity from installation to failure, or from a failureto a subsequent failure. Thus, the failure estimator can indicate aruntime to or between failures from, respectively, installation orfailure to failure. Because other statistical analysis can be used todetermine the time to failure (e.g., lifetime) estimator, it should beunderstood that this example is illustrative, and therefore should notbe construed as being limiting in any way.

The service level agreement management service 112 can also beconfigured to identify a statistical distribution that can represent thefailure estimator. According to some embodiments of the concepts andtechnologies disclosed herein, the service level agreement managementservice 112 can be configured to perform a fit of probabilitydistributions to the failure estimator, and to select a best-fitdistribution (based on metrics of the failure estimator) and associatedparameters for the best-fit distribution (e.g., parameters that canrelate to the type of device, the utilization and/or other usecharacteristics of the device, combinations thereof, or the like). Theresulting probability distribution and parameters can model the failuresof the services 106, devices hosting the services 106, and/or otherentities; as observed (e.g., in the failure data set 120) and/or asprojected (e.g., based on the failure data set 120 and/or the inventorydata set 122), and therefore can be output as the failure models 124. Itshould be understood that this example is illustrative, and thereforeshould not be construed as being limiting in any way.

In some embodiments, as shown in FIG. 1, a user device 126 cancommunicate with the server computer 114 (and the service levelagreement management service 112), e.g., via a portal or applicationprogramming interface exposed by the server computer 114, or the like.The user device 126 can be configured to generate a request 128 for arepresentation of the failure models 124, and the service levelagreement management service 112 can be configured to provide, to theuser device 126, one or more graphical representations 130. Thegraphical representations 130 can include display data that, whenrendered by the user device 126 and/or presented in a web page, portal,or the like; can represent the failure models 124. Some examplegraphical representations 130 are illustrated and described herein withreference to FIGS. 3A-3C. Because other types of graphicalrepresentations 130 can be generated in accordance with the concepts andtechnologies disclosed herein, it should be understood that theseexamples are illustrative, and therefore should not be construed asbeing limiting in any way.

The service level agreement management service 112 can also beconfigured to send, to a service level agreement management entity 132,the failure models 124 and/or information for one or more changes thatshould be made to a service level agreement such as, for example, one ormore updates to the service level agreements. The service levelagreement management entity 132 can operate on or in communication withthe network 104 and can be responsible, in some embodiments, for themanagement of service level agreements for the services 106 and/or usersof the services 106. In some embodiments, the service level agreementmanagement service 112 can be configured to perform the functionality ofthe service level agreement management entity 132, and the service levelagreement management entity 132 can therefore be omitted in variousembodiments of the concepts and technologies disclosed herein. It shouldbe understood that this example is illustrative, and therefore shouldnot be construed as being limiting in any way.

The service level agreement management entity 132 can be configured toreceive the failure models 124, and to generate, based on the failuremodels 124, one or more service level agreement updates 134. The servicelevel agreement updates 134 can include commands, instructions, and/orother code for causing a recipient to modify a service level agreementassociated with a service 106, device, or the like. According to variousembodiments of the concepts and technologies disclosed herein, theservice level agreement updates 134 can be received by the customerpremises equipment 102 and/or one or more of the services 106, and aservice level agreement associated with the one or more services 106 canbe modified based on the service level agreement updates 134. Thus, forexample, if a failure model 124 indicates that a particular service 106is likely to fail at a particular time, the service level agreementmanagement service 112 can be configured to modify the service levelagreement associated with the service 106 before the expected time ofthe failure, thereby avoiding a failure to meet a quality of service orother metric associated with the service level agreement for thatservice 106. In some embodiments, the service level agreement updates134 can include suggestions for a next revision of the applicableservice level agreement, and therefore is not immediately implemented.It should be understood that this example is illustrative, and thereforeshould not be construed as being limiting in any way.

Although the example embodiment illustrated in FIG. 1 shows the servercomputer 114 sending the failure models 124 to the service levelagreement management entity 132, and the service level agreementmanagement entity 132 generating the service level agreement updates 134for providing to the services 106 and/or customer premises equipment102, it should be understood that this example is illustrative. Inparticular, some embodiments of the concepts and technologies disclosedherein include the service level agreement management service 112generating service level agreement updates 134 and sending thosedirectly to the services 106 and/or the customer premises equipment 102.As such, the illustrated embodiment is illustrative and should not beconstrued as being limiting in any way.

According to various embodiments of the concepts and technologiesdisclosed herein, the service level agreement management service 112 canbe configured to generate failure models 124 for one or more service106, devices associated with the service 106, other devices such as thecustomer premises equipment 102 and/or the devices 108, and the like. Insome embodiments, a failure model 124 can be generated for specificfailure root causes, thereby enabling specific root causes to beanalyzed and/or to enable analysis of certain hardware (e.g., thecustomer premises equipment 102). Thus, failure models 124 can begenerated for all devices and/or other entities associated with aservice 106 and/or all services 106 associated with a particularcustomer premises equipment 102, thereby enabling the creation of afailure profile for the service 106 (across users) and/or a customerpremises equipment 102 (across services 106). It should be understoodthat these example embodiments are illustrative, and therefore shouldnot be construed as being limiting in any way.

In practice, a customer premises equipment 102 can operate on a customerpremises. The customer premises equipment 102 can access one or moreservices 106 for providing various types of functionality and/or canenable a connection between the services 106 and one or more deviceslocated at or in proximity to a customer premises 110. The services 106can have one or more service level agreements that can define variousaspects of the quality of service and/or quality of experience for theservices 106, users of the services 106, or the like. A network monitor116 can be configured to monitor the services 106, the customer premisesequipment 102, and/or the devices 108; or these and/or other devices onor in communication with the network 104 can be configured toself-report performance and/or failure information to one or moreentities as illustrated and described herein.

In various embodiments of the concepts and technologies disclosedherein, a service level agreement management service 112 can operateand/or be hosted by a server computer 114. The service level agreementmanagement service 112 can be configured to obtain network data 118 fromthe customer premises equipment 102, the service 106, the devices 108,and/or other devices and/or entities. The network data 118 can includefailure data that can describe one or more failures of these or otherentities; time data describing times of failures and/or times of entityinstallation; service level agreement data that describes one or moreservice level agreements associated with the services and/or otherentities; resolution data that can describe how failures have beenremediated and/or resolved; other data; combinations thereof; or thelike. The service level agreement management service 112 can analyze thenetwork data 118 and generate, based on the network data 118, a failuredata set 120 and an inventory data set 122.

The failure data set 120 can describe failures of entities such asservices 106 and/or devices accessing, using, or enabling use or accessto, the services 106; and time information associated with the entitiessuch as times between failures. The inventory data set 122 can describethe entities and the time since installation for the entities. Theservice level agreement management service 112 can be configured tohorizontally bind the failure data set 120 to the inventory data set 122so that each record in the resulting bound data sets will include a timevalue; either a time since installation (in the event of no failure) ora time between failures. The service level agreement management service112 can generate a failure estimator for the data set.

In some embodiments, the failure estimator can be generated for a subsetof the bound data sets and can be obtained by performing anon-parametric estimation of the probability of failure over time forthe data sets or subset. The service level agreement management service112 can also perform a fit of probability distributions to identify abest-fit probability distribution for the failure estimator. Thisbest-fit probability distribution can be output as a failure model 124and/or associated parameters, in some embodiments. In some embodiments,the service level agreement management service 112 can generategraphical representations of the failure models 124, for example inresponse to a request 128, to enable visual representation of thefailure estimator. It should be understood that this example isillustrative, and therefore should not be construed as being limiting inany way.

The service level agreement management service 112 also can provide thefailure models 124 to a service level agreement management entity 132,and the service level agreement management entity 132 can determine ifone or more service level agreements associated with the service 106 orother entity being considered should be updated based on an anticipatedfailure. If a failure is determined to be imminent, the service levelagreement management entity 132 can generate one or more service levelagreement updates 134 and provide those updates to an entity forimplementation (e.g., to adjust an service level agreement). In someother embodiments, the service level agreement management service 112can generate the service level agreement updates 134 and provide thoseservice level agreement updates 134 to various entities forimplementation and/or for reporting purposes. Thus, some embodiments ofthe concepts and technologies disclosed herein can be used to minimizerisk associated with failing to meet quality of service commitments byproactively changing associated service level agreements. It should beunderstood that this example is illustrative, and therefore should notbe construed as being limiting in any way.

FIG. 1 illustrates one customer premises equipment 102, one network 104,two services 106, two devices 108, one customer premises 110, one servercomputer 114, one network monitor 116, and one service level agreementmanagement entity 132. It should be understood, however, that variousimplementations of the operating environment 100 can include zero, one,or more than one customer premises equipment 102; zero, one, or morethan one network 104; one, two, or more than two services 106; zero,one, two, or more than two devices 108; zero, one, or more than onecustomer premises 110; zero, one, or more than one server computer 114;zero, one, or more than one network monitor 116; and/or zero, one, ormore than one service level agreement management entity 132. As such,the illustrated embodiment should be understood as being illustrative,and should not be construed as being limiting in any way.

Turning now to FIG. 2, aspects of a method 200 for managing servicelevel agreements using a service level agreement management service willbe described in detail, according to an illustrative embodiment. Itshould be understood that the operations of the methods disclosed hereinare not necessarily presented in any particular order and thatperformance of some or all of the operations in an alternative order(s)is possible and is contemplated. The operations have been presented inthe demonstrated order for ease of description and illustration.Operations may be added, omitted, and/or performed simultaneously,without departing from the scope of the concepts and technologiesdisclosed herein.

It also should be understood that the methods disclosed herein can beended at any time and need not be performed in its entirety. Some or alloperations of the methods, and/or substantially equivalent operations,can be performed by execution of computer-readable instructions includedon a computer storage media, as defined herein. The term“computer-readable instructions,” and variants thereof, as used herein,is used expansively to include routines, applications, applicationmodules, program modules, programs, components, data structures,algorithms, and the like. Computer-readable instructions can beimplemented on various system configurations including single-processoror multiprocessor systems, minicomputers, mainframe computers, personalcomputers, hand-held computing devices, microprocessor-based,programmable consumer electronics, combinations thereof, and the like.

Thus, it should be appreciated that the logical operations describedherein are implemented (1) as a sequence of computer implemented acts orprogram modules running on a computing system and/or (2) asinterconnected machine logic circuits or circuit modules within thecomputing system. The implementation is a matter of choice dependent onthe performance and other requirements of the computing system.Accordingly, the logical operations described herein are referred tovariously as states, operations, structural devices, acts, or modules.These states, operations, structural devices, acts, and modules may beimplemented in software, in firmware, in special purpose digital logic,and any combination thereof. As used herein, the phrase “cause aprocessor to perform operations” and variants thereof is used to referto causing a processor of a computing system or device, such as theserver computer 114, to perform one or more operations and/or causingthe processor to direct other components of the computing system ordevice to perform one or more of the operations.

For purposes of illustrating and describing the concepts of the presentdisclosure, the method 200 is described herein as being performed by theserver computer 114 via execution of one or more software modules suchas, for example, the service level agreement management service 112. Itshould be understood that additional and/or alternative devices and/ornetwork nodes can provide the functionality described herein viaexecution of one or more modules, applications, and/or other softwareincluding, but not limited to, the service level agreement managementservice 112. Thus, the illustrated embodiments are illustrative, andshould not be viewed as being limiting in any way.

The method 200 begins at operation 202. At operation 202, the servercomputer 114 can obtain network data such as the network data 118illustrated and described with reference to FIG. 1. As explained herein,the network data 118 can be provided to the service level agreementmanagement service 112 (or the server computer 114 that hosts theservice level agreement management service 112), in some embodiments, bythe network monitor 116. In some embodiments, the network data 118 canbe provided to the server computer 114 and/or the service levelagreement management service 112 by one or more services 106.

In yet other embodiments of the concepts and technologies disclosedherein, the network data 118 can be provided to the server computer 114and/or the service level agreement management service 112 by thecustomer premises equipment 102 and/or one or more of the devices 108.Thus, it can be appreciated that one or more entities can provide thenetwork data 118 to the server computer 114 and/or the service levelagreement management service 112 in accordance with various embodimentsof the concepts and technologies disclosed herein. Because the networkdata 118 can be obtained by the server computer 114 in a variety ofmanners, it should be understood that these examples are illustrative,and therefore should not be construed as being limiting in any way.

From operation 202, the method 200 can proceed to operation 204. Atoperation 204, the server computer 114 can create a failure data set 120and an inventory data set 122. In particular, as noted above, the servercomputer 114 can generate the failure data set 120 and the inventorydata set 122 based on the network data 118. In various embodiments, asexplained in detail above, then network data 118 can include failuredata, time data, service level agreement data, resolution data, otherdata, and the like. Thus, in operation 204, the server computer 114 cangenerate, based on the network data 118, a failure data set 120 that canrepresent failures and times between failures.

The server computer 114 also can generate, based on the network data118, an inventory data set 122 that can represent services 106 and/orcomponents thereof (e.g., resources that host services 106, users ofservices 106, network resources associated with services 106,combinations thereof, or the like) and a time since installation foreach of the services 106 and/or components thereof. As such, asexplained herein, the failure data set 120 and the inventory data set122 can define, for a service 106, device associated with and/or usingthe service 106, and/or components thereof failure information, timeinformation associated with failures, and/or a time since initializationof the service 106, device associated with and/or using the service,and/or components thereof

From operation 204, the method 200 can proceed to operation 206. Atoperation 206, the server computer 114 can bind the failure data set 120to the inventory data set 122. As noted above, the binding cancorrespond to a horizontal binding of the data sets such that each rowin the resulting bound data set can include a time between failuresand/or a time since installation. Thus, it can be appreciated that eachrecord in the bound data sets in various embodiments can include a timeparameter. It should be understood that this example is illustrative,and therefore should not be construed as being limiting in any way.

From operation 206, the method 200 can proceed to operation 208. Atoperation 208, the server computer 114 can select a data partition byfailure root cause. In particular, as noted above the server computer114 can be configured to generate an intermediate data set in someembodiments by binding the failure data set 120 to the inventory dataset 122, and in operation 208 the server computer 114 can be configuredto select or filter the intermediate data set based on a particular rootcause. For example, a processing resource failure can be used as a rootcause filter on the intermediate data set (or on the bound data sets) toidentify all failures associated with that particular root cause.Operations 208-214 can be iterated on the sub-set of data from thisfiltered intermediate data set to model failures associated with thatspecific root cause, as will be explained in more detail.

From operation 208, the method 200 can proceed to operation 210. Atoperation 210, the server computer 114 can determine a failure estimatorfor the sub-set of data as selected in operation 208 (e.g., for thecurrently-considered root cause). As explained above, the failureestimator determined in operation 210 can correspond to a non-parametricestimation of a probability of failure over time for a particular entitysuch as, for example, a service 106, a device hosting a service 106, adevice accessing or using the service 106, a device enabling access oruse of the service 106 such as the customer premises equipment 102,devices accessing the service 106 such as the devices 108, combinationsthereof, or the like. Furthermore, as is clear from FIG. 2, the failureestimator determined in operation 210 can be determined for the selectedroot cause, as the data used to generate the failure estimator inoperation 210 can be a sub-set of the bound failure data set 120 andinventory data set 122. It should be understood that this example isillustrative, and therefore should not be construed as being limiting inany way.

Thus, in operation 210 a failure estimator can be generated for one ormore entities as represented by the network data 118. In some exampleembodiments, a failure estimator can be generated in operation 210 forthe customer premises equipment 102 (e.g., a failure estimator for thecustomer premises equipment 102 across multiple services 106), a service106 (e.g., a failure estimator for a particular service 106 acrossmultiple users such as, for example, the customer premises equipment102), other devices and/or entities, combinations thereof, or the like;for a selected root cause. It should be understood that this example isillustrative, and therefore should not be construed as being limiting inany way.

As noted above, the failure estimator can be generated, in someembodiments, the server computer 114 applying, to the bound data sets, aKaplan-Meier estimate to determine the probability of a failure overtime for the selected root cause for a particular device, service 106,and/or other entity. Because the failure estimator can be obtained inadditional and/or alternative manners, it should be understood that thisexample is illustrative, and therefore should not be construed as beinglimiting in any way.

From operation 210, the method 200 can proceed to operation 212. Atoperation 212, the server computer 114 can determine a distributionbased on the failure estimator determined in operation 210. Thus,operation 212 can correspond to the server computer 114 identifying abest-fit distribution for the failure estimator from multiplestatistical distributions. It should be understood that this example isillustrative, and therefore should not be construed as being limiting inany way.

From operation 212, the method 200 can proceed to operation 214. Atoperation 214, the server computer 114 can determine if another datapartition exists for analysis. It can be appreciated from the abovedescription that because operation 214 relates to data partitions basedon root causes (of failures), that operation 214 can be performed withrespect to the failure data set 120 and not the inventory data set 122.It should be understood that this example is illustrative, and thereforeshould not be construed as being limiting in any way.

As noted above with reference to operation 208, the server computer 114can be configured to select a first data partition based on a particularroot cause in operation 208. Thus, operation 214 can correspond to theserver computer 114 determining if any more root causes have beenidentified in the bound data sets for consideration. Thus, the servercomputer 114 can track a number of iterations of operations 208-214 anddetermine, in operation 214, if all root causes have been considered orwhether additional data partitions associated with remaining root causesexist. Because the determination of operation 214 can be made inadditional and/or alternative manners, it should be understood that thisexample is illustrative, and therefore should not be construed as beinglimiting in any way.

If the server computer 114 determines, in operation 214, that anotherpartition exists for analysis, the method 200 can return to operation208, and the server computer 114 can select another data partition(e.g., another root cause for filtering the bound data sets). Thus,operations 208-214 can be iterated until the server computer 114determines, in any iteration of operation 214, that no additionalpartition exists for analysis. If the server computer 114 determines, inany iteration of operation 214, that no additional partition exists foranalysis, the method 200 can proceed to operation 216.

At operation 216, the server computer 114 can output one or more failuremodels such as the failure models 124 and one or more graphicalrepresentations such as the graphical representations 130. In someembodiments, though not separately shown in FIG. 2, the server computer114 can receive a request such as the request 128 for the graphicalrepresentations 130, and the server computer 114 can respond to therequest 128 with the graphical representations 130. It should beunderstood that this example is illustrative, and therefore should notbe construed as being limiting in any way.

The failure models 124 output in operation 216 can include the best-fitdistribution and parameters for each of the root causes considered overone or more iterations of operations 208-214. Thus, it can beappreciated that in various embodiments of the concepts and technologiesdisclosed herein, operation 216 can correspond to the server computer114 outputting multiple distributions with multiple sets of parametersas the failure models 124. Thus, in some embodiments of operation 216,the server computer 114 can provide failure models 124 for an entireservice 106 (e.g., over multiple devices and/or users), for a particularpiece of hardware (e.g., the customer premises equipment 102), or thelike. It should be understood that this example is illustrative, andtherefore should not be construed as being limiting in any way.

From operation 216, the method 200 can proceed to operation 218. Atoperation 218, the server computer 114 can determine if a service levelagreement should be updated. In operation 218, the server computer 114can consider the failure models 124 and determine, based on the failuremodels 124, if any service 106, device hosting, accessing, or using theservice 106, customer premises equipment 102, or other device or entityshould have a service level agreement modified based on an expectedfailure. Thus, operation 218 can correspond to the server computer 114applying one or more failure models 124 to a service 106, the customerpremises equipment 102, and/or other devices or entities to determine ifa failure is expected soon (e.g., within a defined time period), or thelike. For example, if a failure model 124 shows a distribution with amean of one thousand hours between or to a failure, and if a service 106or component thereof has been operating for over one thousand hourssince a failure or installation, the server computer 114 can determinethat a failure of that service 106 is imminent in operation 218, andthat an associated service level agreement should therefore be modifiedto reduce liability for the service provider (e.g., liability forfailing to meet a QoS specified in the service level agreement, or thelike). Because the server computer 114 can determine that a servicelevel agreement should be modified for additional and/or alternativereasons, it should be understood that this example is illustrative, andtherefore should not be construed as being limiting in any way.

If the server computer 114 determines, in operation 218, that a servicelevel agreement should be updated, the method 200 can proceed tooperation 220. At operation 220, the server computer 114 can trigger anupdate to one or more service level agreements. In some embodiments, forexample, the server computer 114 can be configured to generate one ormore service level agreement updates 134 and/or to deliver the servicelevel agreement updates 134 to the affected service(s) 106.

In some other embodiments, the server computer 114 can provide thefailure models 124 to one or more service level agreement managemententities 132, and the service level agreement management entity 132 canbe configured to generate the one or more service level agreementupdates 134. The service level agreement management entity 132 can beconfigured to provide the service level agreement updates 134 to theservices 106 and/or components thereof, in some embodiments. Because theservice level agreement updates 134 can be generated and/or delivered inadditional and/or alternative manners, it should be understood that theabove examples are illustrative, and therefore should not be construedas being limiting in any way.

In some embodiments of operation 220, the server computer 114 can applyvarious business service level agreement requirements to the failuremodels 124 to identify one or more service level agreement changes thatshould be made. In some embodiments, these changes may be made to reduceliability, as noted above, to improve a customer's perceived quality ofexperience, and/or for other reasons. Because the determination ofoperation 220 can be made in a variety of manners, it should beunderstood that these examples are illustrative, and therefore shouldnot be construed as being limiting in any way.

From operation 218, the method 200 can proceed to operation 222. Themethod 200 also can proceed to operation 222 from operation 218 if theserver computer 114 determines, in operation 218, that a service levelagreement should not be updated. At operation 222, the method 200 canend.

FIGS. 3A-3C are user interface (“UI”) diagrams showing aspects of UIsfor using and/or interacting with the service level agreement managementservice 112, according to some illustrative embodiments. FIG. 3A showsan illustrative screen display 300A. According to some embodiments ofthe concepts and technologies described herein, the screen display 300Acan be generated by a device such as the user device 126 viainteractions with the service level agreement management service 112. Inparticular, according to various embodiments, the user device 126 cangenerate the screen display 300A based on the graphical representations130 obtained from the service level agreement management service 112.Because the screen display 300A can be generated based on otherinformation and/or data, it should be understood that this example isillustrative, and therefore should not be construed as being limiting inany way. Furthermore, it should be appreciated that the UI diagramillustrated in FIG. 3A is illustrative of one contemplated example ofthe UIs that can be generated and/or displayed in accordance with theconcepts and technologies disclosed herein, and therefore should not beconstrued as being limiting in any way.

It can be appreciated with reference to FIG. 3A that the screen display300A can include representations and/or depictions of statisticalequations; look-up tables to describe the continuous function; and/ordiscrete lookup capabilities (e.g., probability of a failure over time).Thus, it should be understood that the UI diagram shown in FIG. 3A(and/or other FIGURES) may be interactive and may be used to determinevalues (e.g., a probability of a failure at a particular time) and notmerely to depict an associated statistical distribution or the like. Itshould be understood that this example is illustrative, and thereforeshould not be construed as being limiting in any way.

According to various embodiments, the screen display 300A can bepresented, for example, in response to the user device 126 sending arequest 128 to the server computer 114, and the user device 126receiving the graphical representations 130 from the server computer114. Because the screen display 300A illustrated in FIG. 3A can bedisplayed at additional and/or alternative times, it should beunderstood that these examples are illustrative and therefore should notbe construed as being limiting in any way.

The screen display 300A can include various menus and/or menu options(not shown in FIG. 3A). The screen display 300A also can include adistribution fit window 302. The distribution fit window 302 can beconfigured to present, to a viewer or user (e.g., the user of the userdevice 126), a graph showing failures of a particular service 106,customer premises equipment 102, other device, and/or entity over time.As shown in FIG. 3A, the distribution fit window 302 can includerepresentations 304A-C of specific failures and their associated timevalues (on the x axis) and a cumulative probability (y axis) of thefailures occurring at the associated time.

For example, the representation 304A is illustrated as occurring at atime value of twenty (e.g., twenty months from the last failure orinstallation; twenty hours from the last failure or installation; twentyminutes from the last failure or installation, etc.) and having acumulative probability of approximately 0.55. While the illustratedembodiment shows time in terms of months, it should be understood thatthis example is illustrative and should not be construed as beinglimiting in any way. In particular, other time units are possible andare contemplated such as, for example, milliseconds, seconds, minutes,hours, days, weeks, etc. Similarly, the representation 304B isillustrated as occurring at a time value of about twenty four (e.g.,twenty four months from the last failure or installation; twenty fourhours from the last failure or installation; twenty four minutes fromthe last failure or installation, etc.) and having a cumulativeprobability of approximately 0.60.

Finally, the representation 304C is illustrated as occurring at a timevalue of about twenty eight (e.g., twenty eight months from the lastfailure or installation; twenty eight hours from the last failure orinstallation; twenty eight minutes from the last failure orinstallation, etc.) and having a cumulative probability of approximately0.82. It should be understood that these examples are illustrative, andtherefore should not be construed as being limiting in any way.

As shown in FIG. 3A, the distribution fit window 302 also can representthe fit distribution by including a distribution curve 306, a firstregion 308 corresponding to an upper confidence interval, and a secondregion 310 corresponding to a lower confidence interval. In the exampleembodiment, the distribution fit window 302 also includes an indicator312 that can provide a readable indicator that identifies the best-fitdistribution and an associated parameter. It should be understood thatthis example is illustrative, and therefore should not be construed asbeing limiting in any way. Because additional or alternative graphicalelements can be included in the distribution fit window 302, it shouldbe understood that the example embodiment shown in FIG. 3A isillustrative and therefore should not be construed as being limiting inany way.

FIG. 3B shows an illustrative screen display 300B. According to someembodiments of the concepts and technologies described herein, thescreen display 300B can be generated by a device such as the user device126 via interactions with the service level agreement management service112. In particular, according to various embodiments, the user device126 can generate the screen display 300B based on the graphicalrepresentations 130 obtained from the service level agreement managementservice 112. Because the screen display 300B can be generated based onother information and/or data, it should be understood that this exampleis illustrative, and therefore should not be construed as being limitingin any way. Furthermore, it should be appreciated that the UI diagramillustrated in FIG. 3B is illustrative of one contemplated example ofthe UIs that can be generated and/or displayed in accordance with theconcepts and technologies disclosed herein, and therefore should not beconstrued as being limiting in any way.

According to various embodiments, the screen display 300B can bepresented, for example, in response to the user device 126 sending arequest 128 to the server computer 114, and the user device 126receiving the graphical representations 130 from the server computer114. Because the screen display 300B illustrated in FIG. 3B can bedisplayed at additional and/or alternative times, it should beunderstood that these examples are illustrative and therefore should notbe construed as being limiting in any way.

The screen display 300B can include various menus and/or menu options(not shown in FIG. 3B). The screen display 300B also can include afailure estimator window 320. The failure estimator window 320 can beconfigured to present, to a viewer or user (e.g., the user of the userdevice 126), a representation of the failure estimator illustrated anddescribed herein for a particular service 106, customer premisesequipment 102, other device, and/or entity over time. As shown in FIG.3B, the failure estimator window 320 can depict probability of a failureat a particular time and/or a time associated with a particularprobability. In the example embodiment, twelve and a half months havepassed since the installation of a particular service 106, customerpremises equipment 102, device accessing the service 106 and/or customerpremises equipment 102, etc. It should be understood that this exampleis illustrative, and therefore should not be construed as being limitingin any way.

The failure estimator window 320 therefore can show the probability ofan imminent failure based on the time lapsed (twelve and half months).As shown in FIG. 3B, the probability of an imminent failure at twelveand a half months for the failure estimator as represented in the fitdistribution shown in FIG. 3A is approximately 0.070901, as indicatedgenerally at reference numeral 322. It should be understood that thisexample is illustrative, and therefore should not be construed as beinglimiting in any way.

Thus, it can be appreciated that the failure estimator window can beused to determine the probability of a failure at a particular time, andtherefore can be used to view and/or provide functionality associatedwith the failure models 124 as set forth herein. It should be understoodthat this example is illustrative, and therefore should not be construedas being limiting in any way. Because additional or alternativegraphical elements can be included in the failure estimator window 320,it should be understood that the example embodiment shown in FIG. 3B isillustrative and therefore should not be construed as being limiting inany way.

FIG. 3C shows an illustrative screen display 300C. The screen display300C can include various menus and/or menu options (not shown in FIG.3C). The screen display 300C also can include additional embodiments ofa failure estimator window 324. The failure estimator window 324 can beconfigured to present, to a viewer or user (e.g., the user of the userdevice 126), a representation of the failure estimator illustrated anddescribed herein for a particular service 106, customer premisesequipment 102, other device, and/or entity over time. Because thefunctionality of the failure estimator window 324 has already beendescribed, additional details of this embodiment are not provided here.It should be understood that this example is illustrative, and thereforeshould not be construed as being limiting in any way. Because additionalor alternative graphical elements can be included in the failureestimator window 324, it should be understood that the exampleembodiment shown in FIG. 3C is illustrative and therefore should not beconstrued as being limiting in any way.

Turning now to FIG. 4, additional details of the network 104 areillustrated, according to an illustrative embodiment. The network 104includes a cellular network 402, a packet data network 404, for example,the Internet, and a circuit switched network 406, for example, apublicly switched telephone network (“PSTN”). The cellular network 402includes various components such as, but not limited to, basetransceiver stations (“BTSs”), Node-B's or e-Node-B's, base stationcontrollers (“BSCs”), radio network controllers (“RNCs”), mobileswitching centers (“MSCs”), mobile management entities (“MMEs”), shortmessage service centers (“SMSCs”), multimedia messaging service centers(“MMSCs”), home location registers (“HLRs”), home subscriber servers(“HSSs”), visitor location registers (“VLRs”), charging platforms,billing platforms, voicemail platforms, GPRS core network components,location service nodes, an IP Multimedia Subsystem (“IMS”), and thelike. The cellular network 402 also includes radios and nodes forreceiving and transmitting voice, data, and combinations thereof to andfrom radio transceivers, networks, the packet data network 404, and thecircuit switched network 406.

A mobile communications device 408, such as, for example, a cellulartelephone, a user equipment, a mobile terminal, a PDA, a laptopcomputer, a handheld computer, and combinations thereof, can beoperatively connected to the cellular network 402. The cellular network402 can be configured as a 2G GSM network and can provide datacommunications via GPRS and/or EDGE. Additionally, or alternatively, thecellular network 402 can be configured as a 3G UMTS network and canprovide data communications via the HSPA protocol family, for example,HSDPA, EUL (also referred to as HSDPA), and HSPA+. The cellular network402 also is compatible with 4G mobile communications standards, 5Gmobile communications standards, other mobile communications standards,and evolved and future mobile communications standards.

The packet data network 404 includes various devices, for example,servers, computers, databases, and other devices in communication withone another, as is generally known. The packet data network 404 devicesare accessible via one or more network links. The servers often storevarious files that are provided to a requesting device such as, forexample, a computer, a terminal, a smartphone, or the like. Typically,the requesting device includes software (a “browser”) for executing aweb page in a format readable by the browser or other software. Otherfiles and/or data may be accessible via “links” in the retrieved files,as is generally known. In some embodiments, the packet data network 404includes or is in communication with the Internet. The circuit switchednetwork 406 includes various hardware and software for providing circuitswitched communications. The circuit switched network 406 may include,or may be, what is often referred to as a plain old telephone system(POTS). The functionality of a circuit switched network 406 or othercircuit-switched network are generally known and will not be describedherein in detail.

The illustrated cellular network 402 is shown in communication with thepacket data network 404 and a circuit switched network 406, though itshould be appreciated that this is not necessarily the case. One or moreInternet-capable devices 410, for example, a PC, a laptop, a portabledevice, or another suitable device, can communicate with one or morecellular networks 402, and devices connected thereto, through the packetdata network 404. It also should be appreciated that theInternet-capable device 410 can communicate with the packet data network404 through the circuit switched network 406, the cellular network 402,and/or via other networks (not illustrated).

As illustrated, a communications device 412, for example, a telephone,facsimile machine, modem, computer, or the like, can be in communicationwith the circuit switched network 406, and therethrough to the packetdata network 404 and/or the cellular network 402. It should beappreciated that the communications device 412 can be anInternet-capable device, and can be substantially similar to theInternet-capable device 410. In the specification, the network 104 isused to refer broadly to any combination of the networks 402, 404, 406.It should be appreciated that substantially all of the functionalitydescribed with reference to the network 104 can be performed by thecellular network 402, the packet data network 404, and/or the circuitswitched network 406, alone or in combination with other networks,network elements, and the like.

FIG. 5 is a block diagram illustrating a computer system 500 configuredto provide the functionality described herein for a service levelagreement management service, in accordance with various embodiments ofthe concepts and technologies disclosed herein. The computer system 500includes a processing unit 502, a memory 504, one or more user interfacedevices 506, one or more input/output (“I/O”) devices 508, and one ormore network devices 510, each of which is operatively connected to asystem bus 512. The bus 512 enables bi-directional communication betweenthe processing unit 502, the memory 504, the user interface devices 506,the I/O devices 508, and the network devices 510.

The processing unit 502 may be a standard central processor thatperforms arithmetic and logical operations, a more specific purposeprogrammable logic controller (“PLC”), a programmable gate array, orother type of processor known to those skilled in the art and suitablefor controlling the operation of the server computer. As used herein,the word “processor” and/or the phrase “processing unit” when used withregard to any architecture or system can include multiple processors orprocessing units distributed across and/or operating in parallel in asingle machine or in multiple machines. Furthermore, processors and/orprocessing units can be used to support virtual processing environments.Processors and processing units also can include state machines,application-specific integrated circuits (“ASICs”), combinationsthereof, or the like. Because processors and/or processing units aregenerally known, the processors and processing units disclosed hereinwill not be described in further detail herein.

The memory 504 communicates with the processing unit 502 via the systembus 512. In some embodiments, the memory 504 is operatively connected toa memory controller (not shown) that enables communication with theprocessing unit 502 via the system bus 512. The memory 504 includes anoperating system 514 and one or more program modules 516. The operatingsystem 514 can include, but is not limited to, members of the WINDOWS,WINDOWS CE, and/or WINDOWS MOBILE families of operating systems fromMICROSOFT CORPORATION, the LINUX family of operating systems, theSYMBIAN family of operating systems from SYMBIAN LIMITED, the BREWfamily of operating systems from QUALCOMM CORPORATION, the MAC OS, iOS,and/or LEOPARD families of operating systems from APPLE CORPORATION, theFREEBSD family of operating systems, the SOLARIS family of operatingsystems from ORACLE CORPORATION, other operating systems, and the like.

The program modules 516 may include various software and/or programmodules described herein. In some embodiments, for example, the programmodules 516 can include the services 106, the service level agreementmanagement service 112, the network monitor 116, the service levelagreement management entity 132, and/or the like. These and/or otherprograms can be embodied in computer-readable media containinginstructions that, when executed by the processing unit 502, perform oneor more of the methods 200 described in detail above with respect toFIG. 2 and/or other functionality as illustrated and described herein.It can be appreciated that, at least by virtue of the instructionsembodying the methods 200 and/or other functionality illustrated anddescribed herein being stored in the memory 504 and/or accessed and/orexecuted by the processing unit 502, the computer system 500 is aspecial-purpose computing system that can facilitate providing thefunctionality illustrated and described herein. According toembodiments, the program modules 516 may be embodied in hardware,software, firmware, or any combination thereof. Although not shown inFIG. 5, it should be understood that the memory 504 also can beconfigured to store the network data 118, the failure data set 120, theinventory data set 122, the failure models 124, the service levelagreement updates 134, and/or other data, if desired.

By way of example, and not limitation, computer-readable media mayinclude any available computer storage media or communication media thatcan be accessed by the computer system 500. Communication media includescomputer-readable instructions, data structures, program modules, orother data in a modulated data signal such as a carrier wave or othertransport mechanism and includes any delivery media. The term “modulateddata signal” means a signal that has one or more of its characteristicschanged or set in a manner as to encode information in the signal. Byway of example, and not limitation, communication media includes wiredmedia such as a wired network or direct-wired connection, and wirelessmedia such as acoustic, RF, infrared and other wireless media.Combinations of the any of the above should also be included within thescope of computer-readable media.

Computer storage media includes only non-transitory embodiments ofcomputer readable media as illustrated and described herein. Thus,computer storage media can include volatile and non-volatile, removableand non-removable media implemented in any method or technology forstorage of information such as computer-readable instructions, datastructures, program modules, or other data. Computer storage mediaincludes, but is not limited to, RAM, ROM, Erasable Programmable ROM(“EPROM”), Electrically Erasable Programmable ROM (“EEPROM”), flashmemory or other solid state memory technology, CD-ROM, digital versatiledisks (“DVD”), or other optical storage, magnetic cassettes, magnetictape, magnetic disk storage or other magnetic storage devices, or anyother medium which can be used to store the desired information andwhich can be accessed by the computer system 500. In the claims, thephrase “computer storage medium” and variations thereof does not includewaves or signals per se and/or communication media.

The user interface devices 506 may include one or more devices withwhich a user accesses the computer system 500. The user interfacedevices 506 may include, but are not limited to, computers, servers,personal digital assistants, cellular phones, or any suitable computingdevices. The I/O devices 508 enable a user to interface with the programmodules 516. In one embodiment, the I/O devices 508 are operativelyconnected to an I/O controller (not shown) that enables communicationwith the processing unit 502 via the system bus 512. The I/O devices 508may include one or more input devices, such as, but not limited to, akeyboard, a mouse, or an electronic stylus. Further, the I/O devices 508may include one or more output devices, such as, but not limited to, adisplay screen or a printer.

The network devices 510 enable the computer system 500 to communicatewith other networks or remote systems via a network, such as the network104. Examples of the network devices 510 include, but are not limitedto, a modem, a radio frequency (“RF”) or infrared (“IR”) transceiver, atelephonic interface, a bridge, a router, or a network card. The network104 may include a wireless network such as, but not limited to, aWireless Local Area Network (“WLAN”) such as a WI-FI network, a WirelessWide Area Network (“WWAN”), a Wireless Personal Area Network (“WPAN”)such as BLUETOOTH, a Wireless Metropolitan Area Network (“WMAN”) such aWiMAX network, or a cellular network. Alternatively, the network 104 maybe a wired network such as, but not limited to, a Wide Area Network(“WAN”) such as the Internet, a Local Area Network (“LAN”) such as theEthernet, a wired Personal Area Network (“PAN”), or a wired MetropolitanArea Network (“MAN”).

FIG. 6 illustrates an illustrative architecture for a cloud computingplatform 600 that can be capable of executing the software componentsdescribed herein for providing a service level agreement managementservice 112 and/or for interacting with the service level agreementmanagement service 112. Thus, it can be appreciated that in someembodiments of the concepts and technologies disclosed herein, the cloudcomputing platform 600 illustrated in FIG. 6 can be used to provide thefunctionality described herein with respect to the customer premisesequipment 102, the services 106, the devices 108, the server computer114, the network monitor 116, the user device 126, the service levelagreement management entity 132, combinations thereof, or the like.

The cloud computing platform 600 thus may be utilized to execute anyaspects of the software components presented herein. Thus, according tovarious embodiments of the concepts and technologies disclosed herein,the customer premises equipment 102, the services 106, the devices 108,the service level agreement management service 112, the server computer114, the network monitor 116, the user device 126, the service levelagreement management entity 132, and/or other devices can beimplemented, at least in part, on or by elements included in the cloudcomputing platform 600 illustrated and described herein. Those skilledin the art will appreciate that the illustrated cloud computing platform600 is a simplification of but only one possible implementation of anillustrative cloud computing platform, and as such, the illustratedcloud computing platform 600 should not be construed as being limitingin any way.

In the illustrated embodiment, the cloud computing platform 600 caninclude a hardware resource layer 602, a virtualization/control layer604, and a virtual resource layer 606. These layers and/or other layerscan be configured to cooperate with each other and/or other elements ofa cloud computing platform 600 to perform operations as will bedescribed in detail herein. While connections are shown between some ofthe components illustrated in FIG. 6, it should be understood that some,none, or all of the components illustrated in FIG. 6 can be configuredto interact with one another to carry out various functions describedherein. In some embodiments, the components are arranged so as tocommunicate via one or more networks such as, for example, the network104 illustrated and described hereinabove (not shown in FIG. 6). Thus,it should be understood that FIG. 6 and the following description areintended to provide a general understanding of a suitable environment inwhich various aspects of embodiments can be implemented, and should notbe construed as being limiting in any way.

The hardware resource layer 602 can provide hardware resources. In theillustrated embodiment, the hardware resources can include one or morecompute resources 608, one or more memory resources 610, and one or moreother resources 612. The compute resource(s) 608 can include one or morehardware components that can perform computations to process data,and/or to execute computer-executable instructions of one or moreapplication programs, operating systems, services, and/or other softwareincluding, but not limited to, the customer premises equipment 102, theservices 106, the devices 108, the server computer 114, the networkmonitor 116, the user device 126, the service level agreement managemententity 132, and/or other devices or entities illustrated and describedherein.

According to various embodiments, the compute resources 608 can includeone or more central processing units (“CPUs”). The CPUs can beconfigured with one or more processing cores. In some embodiments, thecompute resources 608 can include one or more graphics processing units(“GPUs”). The GPUs can be configured to accelerate operations performedby one or more CPUs, and/or to perform computations to process data,and/or to execute computer-executable instructions of one or moreapplication programs, operating systems, and/or other software that mayor may not include instructions that are specifically graphicscomputations and/or related to graphics computations. In someembodiments, the compute resources 608 can include one or more discreteGPUs. In some other embodiments, the compute resources 608 can includeone or more CPU and/or GPU components that can be configured inaccordance with a co-processing CPU/GPU computing model. Thus, it can beappreciated that in some embodiments of the compute resources 608, asequential part of an application can execute on a CPU and acomputationally-intensive part of the application can be accelerated bythe GPU. It should be understood that this example is illustrative, andtherefore should not be construed as being limiting in any way.

In some embodiments, the compute resources 608 also can include one ormore system on a chip (“SoC”) components. It should be understood thatan SoC component can operate in association with one or more othercomponents as illustrated and described herein, for example, one or moreof the memory resources 610 and/or one or more of the other resources612. In some embodiments in which an SoC component is included, thecompute resources 608 can be or can include one or more embodiments ofthe SNAPDRAGON brand family of SoCs, available from QUALCOMM of SanDiego, Calif.; one or more embodiment of the TEGRA brand family of SoCs,available from NVIDIA of Santa Clara, California; one or more embodimentof the HUMMINGBIRD brand family of SoCs, available from SAMSUNG ofSeoul, South Korea; one or more embodiment of the Open MultimediaApplication Platform (“OMAP”) family of SoCs, available from TEXASINSTRUMENTS of Dallas, Texas; one or more customized versions of any ofthe above SoCs; and/or one or more other brand and/or one or moreproprietary SoCs.

The compute resources 608 can be or can include one or more hardwarecomponents arranged in accordance with an ARM architecture, availablefor license from ARM HOLDINGS of Cambridge, United Kingdom.Alternatively, the compute resources 608 can be or can include one ormore hardware components arranged in accordance with an x86architecture, such as an architecture available from INTEL CORPORATIONof Mountain View, Calif., and others. Those skilled in the art willappreciate the implementation of the compute resources 608 can utilizevarious computation architectures and/or processing architectures. Assuch, the various example embodiments of the compute resources 608 asmentioned hereinabove should not be construed as being limiting in anyway. Rather, implementations of embodiments of the concepts andtechnologies disclosed herein can be implemented using compute resources608 having any of the particular computation architecture and/orcombination of computation architectures mentioned herein as well asother architectures.

Although not separately illustrated in FIG. 6, it should be understoodthat the compute resources 608 illustrated and described herein can hostand/or execute various services, applications, portals, and/or otherfunctionality illustrated and described herein. Thus, the computeresources 608 can host and/or can execute the service level agreementmanagement service 112, the network monitor 116, the user device 126,the service level agreement management entity 132, and/or otherapplications or services illustrated and described herein.

The memory resource(s) 610 can include one or more hardware componentsthat can perform or provide storage operations, including temporaryand/or permanent storage operations. In some embodiments, the memoryresource(s) 610 can include volatile and/or non-volatile memoryimplemented in any method or technology for storage of information suchas computer-readable instructions, data structures, program modules, orother data disclosed herein. Computer storage media is definedhereinabove and therefore should be understood as including, in variousembodiments, random access memory (“RAM”), read-only memory (“ROM”),Erasable Programmable ROM (“EPROM”), Electrically Erasable ProgrammableROM (“EEPROM”), flash memory or other solid state memory technology,CD-ROM, digital versatile disks (“DVD”), or other optical storage,magnetic cassettes, magnetic tape, magnetic disk storage or othermagnetic storage devices, or any other medium that can be used to storedata and that can be accessed by the compute resources 608, subject tothe definition of “computer storage media” provided above (e.g., asexcluding waves and signals per se and/or communication media as definedin this application).

Although not illustrated in FIG. 6, it should be understood that thememory resources 610 can host or store the various data illustrated anddescribed herein including, but not limited to, the network data 118,the failure data set 120, the inventory data set 122, the failure models124, the request 128, the graphical representations 130, the servicelevel agreement updates 134, and/or other data, if desired. It should beunderstood that this example is illustrative, and therefore should notbe construed as being limiting in any way.

The other resource(s) 612 can include any other hardware resources thatcan be utilized by the compute resources(s) 608 and/or the memoryresource(s) 610 to perform operations. The other resource(s) 612 caninclude one or more input and/or output processors (e.g., a networkinterface controller and/or a wireless radio), one or more modems, oneor more codec chipsets, one or more pipeline processors, one or morefast Fourier transform (“FFT”) processors, one or more digital signalprocessors (“DSPs”), one or more speech synthesizers, combinationsthereof, or the like.

The hardware resources operating within the hardware resource layer 602can be virtualized by one or more virtual machine monitors (“VMMs”)614A-614N (also known as “hypervisors;” hereinafter “VMMs 614”). TheVMMs 614 can operate within the virtualization/control layer 604 tomanage one or more virtual resources that can reside in the virtualresource layer 606. The VMMs 614 can be or can include software,firmware, and/or hardware that alone or in combination with othersoftware, firmware, and/or hardware, can manage one or more virtualresources operating within the virtual resource layer 606.

The virtual resources operating within the virtual resource layer 606can include abstractions of at least a portion of the compute resources608, the memory resources 610, the other resources 612, or anycombination thereof. These abstractions are referred to herein asvirtual machines (“VMs”). In the illustrated embodiment, the virtualresource layer 606 includes VMs 616A-616N (hereinafter “VMs 616”).

Based on the foregoing, it should be appreciated that systems andmethods for a service level agreement management service have beendisclosed herein. Although the subject matter presented herein has beendescribed in language specific to computer structural features,methodological and transformative acts, specific computing machinery,and computer-readable media, it is to be understood that the conceptsand technologies disclosed herein are not necessarily limited to thespecific features, acts, or media described herein. Rather, the specificfeatures, acts and mediums are disclosed as example forms ofimplementing the concepts and technologies disclosed herein.

The subject matter described above is provided by way of illustrationonly and should not be construed as limiting. Various modifications andchanges may be made to the subject matter described herein withoutfollowing the example embodiments and applications illustrated anddescribed, and without departing from the true spirit and scope of theembodiments of the concepts and technologies disclosed herein.

1. A system comprising: a processor; and a memory that storescomputer-executable instructions that, when executed by the processor,cause the processor to perform operations comprising obtaining networkdata that relates to a service, wherein the network data represents aservice level agreement associated with the service and a failure of acomponent of the service due to a failure root cause, creating, based onthe network data, an inventory data set that describes the component ofthe service and an amount of time the component of the service has beenavailable, determining a failure estimator that estimates, over time, aprobability of failure of the service due to the failure root cause,determining, for the failure estimator, a best-fit probabilitydistribution, outputting a failure model that represents failures overtime for the service due to the failure root cause, and determining,based on the failure model, if the service level agreement should beupdated.
 2. The system of claim 1, wherein the computer-executableinstructions, when executed by the processor, cause the processor toperform operations further comprising: receiving, from a user device, arequest for a graphical representation of the failure model; andproviding, to the user device and in response to the request, thegraphical representation of the failure model.
 3. The system of claim 1,wherein the computer-executable instructions, when executed by theprocessor, cause the processor to perform operations further comprising:triggering creation of a service level agreement update and delivery ofthe service level agreement to the service.
 4. The system of claim 1,wherein the network data is obtained from a network monitor that isconfigured to monitor performance of the service and a customer premisesequipment.
 5. The system of claim 1, wherein the network data describesa time between a first failure of the service and a second failure ofthe service.
 6. The system of claim 1, wherein the inventory data setdescribes a time since an installation of the component of the service.7. The system of claim 1, wherein the computer-executable instructions,when executed by the processor, cause the processor to performoperations further comprising: obtaining a failure data set; and bindingthe failure data set to the inventory data set to obtain an intermediatedata set having a plurality of records, wherein each of the plurality ofrecords specifies a time value associated with the component of theservice, and wherein the time value comprises one of a time betweenfailures for the component of the service or a time since installationof the component of the service.
 8. A method comprising: obtaining, at acomputer comprising a processor, network data that relates to a service,wherein the network data represents a service level agreement associatedwith the service and a failure of a component of the service due to afailure root cause; creating, by the processor and based on the networkdata, an inventory data set that describes the component of the serviceand an amount of time the component of the service has been available;determining, by the processor, a failure estimator that estimates, overtime, a probability of failure of the service due to the failure rootcause; determining, by the processor and for the failure estimator, abest-fit probability distribution; outputting, by the processor, afailure model that represents failures over time for the service due tothe failure root cause; and determining, by the processor and based onthe failure model, if the service level agreement should be updated. 9.The method of claim 8, further comprising: receiving, from a userdevice, a request for a graphical representation of the failure model;and providing, to the user device and in response to the request, thegraphical representation of the failure model.
 10. The method of claim8, further comprising: triggering creation of a service level agreementupdate and delivery of the service level agreement to the service. 11.The method of claim 8, wherein the network data describes a time betweena first failure of the service and a second failure of the service. 12.The method of claim 8, wherein the inventory data set describes a timesince an installation of the component of the service.
 13. The method ofclaim 8, further comprising: obtaining a failure data set; and bindingthe failure data set to the inventory data set to obtain an intermediatedata set having a plurality of records, wherein each of the plurality ofrecords specifies a time value associated with the component of theservice, and wherein the time value comprises one of a time betweenfailures for the component of the service or a time since installationof the component of the service.
 14. A computer storage medium havingcomputer-executable instructions stored thereon that, when executed by aprocessor, cause the processor to perform operations comprising:obtaining network data that relates to a service, wherein the networkdata represents a service level agreement associated with the serviceand a failure of a component of the service due to a failure root cause;creating, based on the network data, an inventory data set thatdescribes the component of the service and an amount of time thecomponent of the service has been available; determining a failureestimator that estimates, over time, a probability of failure of theservice due to the failure root cause; determining, for the failureestimator, a best-fit probability distribution; outputting a failuremodel that represents failures over time for the service due to thefailure root cause; and determining, based on the failure model, if theservice level agreement should be updated.
 15. The computer storagemedium of claim 14, wherein the computer-executable instructions, whenexecuted by the processor, cause the processor to perform operationsfurther comprising: receiving, from a user device, a request for agraphical representation of the failure model; and providing, to theuser device and in response to the request, the graphical representationof the failure model.
 16. The computer storage medium of claim 14,wherein the computer-executable instructions, when executed by theprocessor, cause the processor to perform operations further comprising:triggering creation of a service level agreement update and delivery ofthe service level agreement to the service.
 17. The computer storagemedium of claim 14, wherein the network data is obtained from a networkmonitor that is configured to monitor performance of the service and acustomer premises equipment.
 18. The computer storage medium of claim14, wherein the network data describes a time between a first failure ofthe service and a second failure of the service.
 19. The computerstorage medium of claim 14, wherein the inventory data set describes atime since an installation of the component of the service.
 20. Thecomputer storage medium of claim 14, wherein the computer-executableinstructions, when executed by the processor, cause the processor toperform operations further comprising: obtaining a failure data set; andbinding the failure data set to the inventory data set to obtain anintermediate data set having a plurality of records, wherein each of theplurality of records specifies a time value associated with thecomponent of the service, and wherein the time value comprises one of atime between failures for the component of the service or a time sinceinstallation of the component of the service.